Актуальной задачей подразделения ИТ является обеспечение сохранности данных и непрерывности сервисов. Вирусы, атаки на инфраструктуру, аварии стали ежедневной реальностью, к которой нужно быть всегда готовым. Для виртуальной среды эта задача решается, в том числе, путем создания резервных копий виртуальных машин. Есть несколько способов резервирования, обзор которых мы предлагаем как новичкам в администрировании, так и профессионалам. Протестируйте 5nine Manager Datacenter...
15 июня 2018 года в Санкт-Петербурге состоится одно из самых ожидаемых событий в деловой жизни ИТ-сообщества - XIII Международный Конгресс ИТ-директоров «Белые Ночи». Организатор Конференции – Санкт-Петербургский клуб ИТ-директоров. Всего планируется более 200 участников. Таги:
7 лет назад мы писали про утилиту ESXi-Customizer, которая позволяет добавлять кастомные драйвера в ISO-образ VMware ESXi. У того же автора (Andreas Peetz) есть еще одна замечательная утилита, которая актуальна и на сегодняшний день - ESXi-Customizer-PS. Актуальна - это значит, что ее последняя версия (от 18 апреля этого года) поддерживает последние версии платформ и фреймворка - vSphere 6.7 и PowerCLI 10.
ESXi-Customizer-PS - это PowerShell-скрипт, который на входе принимает большое число различных параметров, а на выходе дает кастомизированный ISO-образ или офлайн-бандл ESXi:
Сценарий имеет три режима работы:
Создать установочный образ ISO или Offline Bundle напрямую из хранилища VMware Online depot (стандартный режим).
Создать установочный образ ISO или Offline Bundle из скачанного ESXi Offline Bundle (параметр -izip).
Обновление локального ESXi Offline Bundle с помощью ESXi patch bundle из хранилища VMware Online depot (параметры -izip -update).
С помощью этих трех режимов вы можете добавлять бандлы из хранилища V-Front Online Depot, либо любого другого Online Depot, указав его URL, а также можно указывать локальные Offline Bundles и VIB-файлы (собственно, кастомные драйверы или кастомный софт под ESXi).
Об использовании утилиты ESXi-Customizer-PS Alex Lopez снял хороший видеотуториал:
Скрипт можно использовать множеством способов. Давайте рассмотрим основные:
1. Вызов скрипта без параметров.
Например:
.\ESXi-Customizer-PS-v2.6.0.ps1
В этом случае утилита создаст ISO-образ ESXi самой последней версии (6.7 на данный момент) и с самым последним уровнем обновлений. Вы также можете указать конкретный номер версии ESXi, для которой будет получен ISO с последними обновлениями. Например:
-v50 : ESXi 5.0 ISO
-v51 : ESXi 5.1 ISO
-v55 : ESXi 5.5 ISO
-v60 : ESXi 6.0 ISO
-v65 : ESXi 6.5 ISO
-v67 : ESXi 6.7 ISO
Также есть еще три параметра:
-outDir : записывать ISO-образ в указанную директорию.
-sip : не использует последний уровень патчей, а показывает меню, где можно выбрать конкретный патч. Новые патчи будут показаны сверху. Также будут показаны и профили, которые содержат только обновления безопасности и/или VMware Tools.
-ozip : на выходе будет сформирован не ISO, а ESXi Offline Bundle, который можно импортировать в Update Manager, указать вручную для обновления черезesxcli или использовать как входной бандл для следующих кастомизаций.
2. Использование офлайн бандла ESXi Offline Bundle как входного параметра (вместо VMware Online depot).
Например, такая команда позволит вам получить ISO-образ из офлайн-бандла:
Офлайн бандл можно скачать через VMware Patch Download portal. Некоторые вендоры также предлагают свои кастомизированные офлайн-бандлы, например HP. Офлайн бандлы VMware можно найти вот тут. Также вы можете использовать параметры из пункта 1.
3. Добавление дополнительных пакетов из присоединенных хранилищ Online depots.
Например, вот эта команда позволит добавить сетевые драйверы, отсутствующие в образе ESXi 5.5:
Данные драйверы есть в VMware Online depot, так как они есть в составе ESXi 5.0 и 5.1, но были исключены из дистрибутива ESXi 5.5. Важно, что для ESXi 6.0 такая штука для этих драйверов уже не прокатит, так как они были добавлены в черный список (blacklised).
4. Присоединение онлайн-хранилища V-Front Online Depot и других хранилищ.
Здесь надо не забывать указывать номер версии патчируемого гипервизора (в данном случае -v60 - это ESXi 6.0).
7. Расширенные параметры.
У утилиты есть еще несколько расширенных параметров, которые дают еще больше возможностей по кастомизации образов ESXi:
-log : указание пути к кастомному лог-файлу.
-test : тестирование возможности построения или обновления образа без накатывания реальных изменений. Экономит массу времени, так как не перестраивает ISO или zip, а также не качает обновления и образы из VMware Online depot.
-nsc : это опция -noSignatureCheck, которая отключает проверку сигнатуры при выполнении функции экспорта. Ее нужно использовать, если вы получаете ошибку типа "Could not find trusted signer." (пакет с некорректными или отсутствующими сигнатурами).
-ipname, -ipdesc, -ipvendor: задание собственных атрибутов в профиле образа. По умолчанию в имени и описании останутся прежние значения с приставкой "customized", а имя вендора не изменится.
-remove vib1[,...]: удаление одного или нескольких VIB-пакетов из кастомного образа.
Скачать ESXi-Customizer-PS-v2.6.0.ps1 можно по этой ссылке.
Мы иногда пишем о том, что большие обновления как хост-серверов VMware ESXi, так и управляющих компонентов VMware vCenter / vCenter Server Appliance всегда лучше ставить заново, а не делать апгрейд с предыдущих версий (если у вас, конечно, есть такая возможность). Да, вы не сохраните логи и исторические данные, но это позволит вам избежать различных проблем, связанных с устаревшими компонентами, которые останутся при обновлении и могут вступить в конфликт с новыми функциями при определенных обстоятельствах.
Такой вот пример приводит и Mike Foley в статье про механизм безопасной загрузки хостов vSphere Secure Boot. Когда он обновил свою инфраструктуру на VMware vSphere 6.7 с версии 6.5, он решил проверить функции Secure Boot и возможности модуля TPM 2.0.
Но когда он включил эти возможности в UEFI BIOS, он получил "розовый экран смерти" (PSOD) сервера ESXi:
Причина оказалась проста - для некоторых legacy-драйверов при обновлении не были обновлены их сигнатуры для VIB-пакетов, поэтому механизм Secure Boot не может эти сигнатуры проверить и выводит хост в PSOD при загрузке.
Чтобы найти эти драйверы, он запустил скрипт secureBoot.py, который показывает модули, препятствующие безопасной загрузке:
/usr/lib/vmware/secureboot/bin/secureBoot.py -c
Вывод оказался примерно таким:
[root@esxi-117] /usr/lib/vmware/secureboot/bin/secureBoot.py -c Secure boot CANNOT be enabled:
Failed to verify signatures of the following vib(s): [
net-tg3
dell-configuration-vib
net-i40e
net-igb
net-ixgbe
vmware-esx-perccli-1.05.08
ima-qla4xxx
misc-cnic-register
net-bnx2
net-bnx2x
net-cnic
net-qlcnic
net-qlge
scsi-bnx2fc
scsi-bnx2i
scsi-qla4xxx
scsi-megaraid-sas
lsu-lsi-mptsas-plugin].
All tardisks validated. All acceptance levels validated
Посмотрев на каждый драйвер по отдельности, он понял, что все это старые Linux-драйверы, которые были заменены в новых версиях VMware vSphere своими Native-аналогами. Например, для драйвера net-tg3 есть аналогичный нативный драйвер ntg3, а для net-bnx2i есть bnxnet.
Поэтому далее Майк просто удалил все VIB-пакеты со старыми драйверами следующей командой:
В итоге его хост смог безопасно загрузиться через Secure Boot. Также Майк далее в статье рассматривает решение еще одной специфической проблемы, которая встречается довольно редко.
Ну а мы еще раз напомним - если есть возможность поставить новую мажорную версию ESXi с нуля - лучше скачайте ISO-образ и сделайте это, вместо того, чтобы "быстро и безопасно" обновиться на новую версию.
Поскольку российское законодательство накладывает ряд требований на процесс обработки и хранения персональных данных (ПДн), компании уже сегодня размещают собственные ПДн в облаке провайдера. Как не нарушить закон и соответствовать требованиям регулятора, какая ответственность возлагается на оператора ПДн и провайдера, что должен знать клиент, выбирая поставщика услуг хостинга персональных данных по ФЗ-152? На эти и другие вопросы ответим в сегодняшней статье...
На сайте проекта VMware Labs появилась очередная утилита DRS Entitlement Viewer, которую давным-давно ожидали пользователи еще с третьей версии ESX Server. Это средство позволяет визуализовать иерархию пулов ресурсов, в которой для каждого пула показаны выделенные ему ресурсы процессора и памяти:
Кроме этого, как вы видите на картинке, также показываются и ресурсы, выделенные всем виртуальным машинам кластера VMware DRS. Эти параметры вычисляются и отображаются на основе фактически потребляемых машинами и пулами ресурсов, а также параметров reservation, limit и shares.
Помимо этого, утилита DRS Entitlement Viewer поддерживает 3 сценария "что если" (What-If):
Изменение настроек reservation, limit и shares для ВМ и/или пула ресурсов.
Что если ВМ будет потреблять столько ресурсов, сколько сможет (то есть нагружена на 100%).
Сочетание обоих предыдущих сценариев.
После применения этих сценариев пользователь сможет увидеть новую картину, которая не повлияет на реальные настройки кластера DRS.
И самое полезное - результат what-if моделирования можно выгрузить в виде консольной команды PowerCLI, которую можно затем применить в реальном окружении VMware vSphere, чтобы получить смоделированную конфигурацию кластера DRS.
Скачать DRS Entitlement Viewer можно по этой ссылке. Работает это как плагин к клиенту vSphere Client на базе технологии HTML5. Для запуска плагина вам потребуется vCenter Server Appliance версии 6.5 или 6.7.
Установить плагин просто:
Распаковываем архив дистрибутива в папку /usr/lib/vmware-vsphere-ui/plugin-packages/.
Добавляем следующие расширенные настройки (Advanced Settings) в кластер HA/DRS:
CompressDrmdumpFiles = 0
DrmdumpResActions = 1
Перезапускаем службу командами:
service-control --stop vsphere-ui
service-control --start vsphere-ui
После этого вы увидите раздел "DRS entitlements" на вкладке "Monitor" для каждого кластера.
На прошлой неделе мы писали о новых возможностях решения для виртуализации и доставки настольных ПК и приложений предприятия VMware Horizon 7.5. А сегодня мы расскажем о новой версии решения App Volumes 2.14, которое предназначено для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам.
Основные новые возможности новой версии App Volumes рассмотрены в видео ниже:
Ну а мы опишем их ниже текстом:
1. Роли и привилегии средствами движка Role-based Access Controls.
Теперь можно делегировать возможности по созданию AppStacks, назначению приложений и выполнению различных задач, таких как, например, мониторинг окружения App Volumes. Можно использовать предустановленные роли, чтобы дать группам Active Directory в консоль App Volumes Manager. Вот какие роли есть по умолчанию:
Administrator
Administrator (Read Only)
AppStacks Administrators
Security Administrators
Writables Administrators
Также можно создавать и кастомные роли с различным набором привилегий.
2. Тома на запись на общих датасторах, расшаренных между серверами vCenter.
Теперь можно расшарить тома Writable Volumes между серверами vCenter с использованием функции Shared Datastores таким образом, чтобы пользователи могли получить доступ к своим томам с разных vCenter. То есть, пользовательское окружение теперь не привязано к конкретному серверу vCenter. Например, пользователь может начать работать в одной сессии со своим Writable Volume, потом выйти из нее, после чего подключиться к другому серверу vCenter и продолжить использовать свой том.
3. Перемещение, резервное копирование и восстановление Writable Volumes.
Теперь с помощью App Volumes Manager можно выполнять следующие операции:
Move Writable Volumes - можно переместить пользовательский том в целях балансировки хранилищ.
Back Up and Restore - можно сделать резервную копию тома, чтобы держать ее вдали от системы. Если том, например, больше не нужен в производственной среде, его можно скопировать, после чего удалить из App Volumes Manager. При необходимости его можно будет восстановить.
Regular Backups - администратор теперь может задать датастор и как часто сбрасывать на него полные копии всех Writable Volumes в системе. Как только пользователь приаттачит том по истечении заданного окна периода, он будет автоматически скопирован на указанный датастор.
4. Поддержка Cached Exchange Mode и Windows Search Indexing.
Индексы Microsoft Outlook и Windows Search теперь сохраняются вместе с файлом Outlook OST на томе Writable Volume. Если User Environment Manager (UEM) настроен так, чтобы редиректить этот OST-файл, то Outlook будет использовать эту конфигурацию.
5. Улучшенная производительность процесса логина.
Если включено асинхронное монтирование, то App Volumes Manager больше не будет ждать пока диски будут смонтированы, перед тем как ответить агенту. Это приводит к тому, что App Volumes Manager может обработать больше одновременных запросов при массовом логине пользователей (boot storm). Также была уменьшена на нагрузка на службы Active Directory и vCenter. В нагруженных конфигурациях администраторы могут настроить mount throttling для снижения пиковой нагрузки на vCenter.
6. Функция One-time Volume Deletion Protection.
В прошлых релизах App Volumes, если переменная окружения AVM_PROTECT_VOLUMES была не добавлена, то App Volumes Manager должен был выполнить несколько операций во время логина, чтобы защитить том от непреднамеренного удаления. Теперь же в vSphere 6.5 и более поздних версиях, App Volumes Manager реализует более эффективную защиту однажды, которая происходит при создании тома.
7. Полугодовой цикл обновления продукта для Windows 10.
Начиная с App Volumes 2.14, поддерживаются версии Windows 10 1709 и 1803. Каждые шесть месяцев Microsoft планирует выпускать обновления своей ОС, и App Volumes также планируется приводить в соответствие с этой гостевой ОС в плане обновления.
8. Фукнции Extended Service Branch (ESB) для Horizon.
Об этих возможностях написано в блоге VMware. Это сервис VMware по предоставлению сервис-паков для некоторых продуктов пользователям бизнес-критичных инфраструктур, которые содержат наиболее важные исправления ошибок и обновления безопасности.
Скачать VMware App Volumes 2.14 можно по этой ссылке.
В конце апреля этого года компания StarWind выпустила обновление лучшего на рынке решения для создания программных iSCSI-хранилищ под виртуализацию - StarWind Virtual SAN. В конце апреля было выпущено большое обновление Virtual SAN v8, а в середине мая был выпущен еще один небольшой апдейт.
Давайте посмотрим, что нового появилось в StarWind Virtual SAN v8 build 12146 и 12166:
Для модуля Cloud Replication появилась поддержка Backblaze B2 Cloud Storage.
Для синхронной репликации и режима обслуживания (maintenance mode) события, описанные в Event Log, стали более детализированными. Вот примеры:
(id 809) Underlying device response time is longer than expected.
(id 824) Partner "%s" request response time is longer than expected.
(id 825) Request execution time is longer than expected.
(id 821) Maintenance mode is turned ON.
(id 822) Maintenance mode is turned OFF.
Несколько изменено поведение кластера - теперь при ручном отключении двух партнерских HA-устройств на сервере оставшийся узел выпадает в состояние "not synchronized". Также если выпадает HA-устройство, а затем Witness-узел, то при возвращении Wintness-узла в онлайн - работоспособность кластера автоматически восстанавливается.
Теперь отсутствует интервал в 30 секунд между отправкой email-нотификаций, также можно поменять SMTP-порт.
Если хранилище создается на устройстве, которое некорректно сообщает о размере физического сектора, StarWind все равно позволяет его создать, но с предупреждением.
Для управления модулем VTL появилась функциональность StarWindX PowerShell. В составе продукта идут вот эти примеры:
Добавлен пример PowerShell-сценария для управления трехузловым HA-кластером на базе LSFS:
\StarWindX\Samples\powershell\CreateHA_3_LSFS.ps1
Для LSFS была исправлена проблема на устройствах pre-V8R6 (при заполненности данными более 1,2 ТБ могла произойти потеря данных при рестарте сервиса). Были исправлены и некоторые проблемы апгрейда LSFS с релиза V8R5. Также было улучшено поведение LSFS при высоких нагрузках (изменена процедура дефрагментации).
В Management Console была добавлена поддержка новой версии продукта StarWind VSA 2.0.
Было сделано множество исправлений ошибок с HA-устройствами, снапшотами и хранилищами.
Очень рекомендуем текущим пользователям StarWind Virtual SAN v8 накатить это обновление (вот инструкция, как это сделать). Ну а тем, кто еще не развертывал StarWind в своей инфраструктуре - рекомендуем попробовать этот продукт бесплатно. Более подробно о решениях StarWind Software можно почитать в Resource Library.
На сайте проекта kauteetech.github.io есть интересный калькулятор vSAN Effective Capacity для показа распределения емкости отказоустойчивых хранилищ VMware vSAN. Он показывает размещение различных областей данных в общем пространстве хранения, организованных на серверных узлах All-flash (все SSD диски) или гибридной модели (SSD для кэша, HDD для данных):
Это очень простая утилита для самой примерной визуализации расчетов. Напомним, что для точного вычисления всех параметров есть VMware vSAN Sizer (он также умеет рассчитывать необходимое число узлов vSAN).
Тип обеспечения отказоустойчивости FTT (число избыточных копий данных)
Штука интересная, поскольку кроме численных параметров сырой и эффективной емкости, наглядно показывает, сколько от общего объема хранилищ занимает сегмент с данными в определенной конфигурации.
Как знают пользователи решения для создания отказоустойчивых кластеров VMware vSAN, этот продукт имеет множество средств для обработки ситуаций отказа физических устройств - дисков HDD и SSD. В vSAN есть специальный механизм Degraded Device Handling (DDH), который приводит кластер в жизнеспособное сосотояние при отказе одного диска или всей дисковой группы. При этом отказом устройства считается не только его полная физическая поломка, но и резкое снижение производительности, что ведет к ухудшению качества обслуживания пользователей.
Давайте посмотрим, как это работает:
1. Механизм DDH в VMware vSAN 6.1.
vSAN 6.1 ищет устройства, на которых операции ввода-вывода вызывают задержки более 50 мс. Если такое поведение на устройстве сохраняется в течение 10 минут, то vSAN отключает это устройство и вызывает аларм. Если таким устройством является кэш-диск, то в офлайн выводится вся дисковая группа (к счастью, современные SSD-диски весьма надежны).
Вот что будет в этом случае в логах:
2015-09-15T02:21:27.270Z cpu8:89341)VSAN Device Monitor: WARNING – READ Average Latency on VSAN device naa.6842b2b006600b001a6b7e5a0582e09a has exceeded threshold value 50 ms 1 times.
2015-09-15T02:21:27.570Z cpu5:89352)VSAN Device Monitor: Unmounting VSAN diskgroup naa.6842b2b006600b001a6b7e5a0582e09a
Компоненты на такой дисковой группе механизм DDH помечает как "Absent". Ребилд для таких компонентов начнется через 60 минут после отказа устройства, когда истечет rebuild timer. Если этот компонент не является частью группы RAID-1 или RAID-5/6, то он становится недоступным.
В случае с RAID-1 все продолжает работать, и если компонент witness работает, то вы получите только оповещение в vSphere Client:
Однако по некоторым причинам выдача больших latency для операций ввода-вывода на диске в течение более чем 10 минут может быть обусловлена некоторыми рабочими моментами, а начинать rebuild дисковой группы в этом случае нежелательно. Поэтому в vSAN 6.2 появились следующие улучшения DDH.
2. Улучшения DDH в vSAN 6.2.
Здесь появилось 4 новых момента:
1. DDH размонтрует диск (кэширующий или обычный) только в случае превышения задержек на запись. При появлении задержек на чтение диск не будет выводиться в офлайн, так как это окажет большее негативное влияние на кластер в целом, чем вывод диска и последующий ребилд.
2. По умолчанию DDH не размонтирует кэш-девайсы и в случае превышения latency на запись. Поскольку это ведет к выводу в офлайн всей дисковой группы, было сделано решение, что такое поведение несет больше вреда, чем медленная работа кэш-устройства. Но это дефолтное поведение можно изменить следующей командой (затрагивает не только кэш, но и диски с данными):
После ее выполнения кэш-устройства и их дисковые группы будут размонтироваться при привышении порога latency на запись.
3. DDH мониторит устройства в рамках случайных 10-минутных интервалов и учитывает несколько таких интервалов. Это предотвращает ложные срабатывания механизма в случае таких операций, как vSAN component recovery, ремапинг секторов HDD-дисков, сбор мусора на SSD и прочее. Теперь для срабатывания DDH нужно 4 превышения latency в непоследовательных 10-минутных интервалах, которые случайно распределены в окне 6-7 часов.
4. DDH пытается снова смонтировать устройства vSAN, которые были ранее размонтированы по превышению latency. Число таких попыток - 24 в окне 24 часа (то есть примерно раз в час). Если условие размонтирования сохраняется, то попытки обратного монтирования прекратятся через сутки.
3. Улучшения DDH в vSAN 6.6 и более поздних версиях.
Эти улучшения базируются на улучшениях в прошлых версиях. Если посмотреть на прошлый пункт, то понятно, что DDH отключает только диски с данными (не трогает кэш-устройства) и только если latency на запись превышает заданное значение.
Для HDD дисков был сделан threshold 500 миллисекунд на запись, для SSD - 50 миллисекунд на чтение и 200 миллисекунд на запись.
Теперь, если вышедший из строя диск является последней копией данных, но с него еще как-то можно получить данные, то vSAN не пометит диск как Absent, но начнет эвакуацию данных, таймер vSAN CLOM Rebuild Timer не включится.
В этом процессе есть 4 стадии:
1. Preventative evacuation in progress - желтый аларм сработает, чтобы дать администратору знать о проблеме. vSAN сам превентивно эвакуирует данные, без необходимых действий со стороны администратора.
2. Preventative evacuation is incomplete due to lack of resources - превентивная эвакуация данных не удалась вследствие недостатка ресурсов. В этом случае будет показан красный аларм. Администратору нужно будет высвободить дисковое пространство, например, удалить ВМ или добавить больше дисков, чтобы завершить эвакуацию данных. Разработчики vSAN рекомендуют на такие случаи держать 25-30% кластера свободными.
3. Preventative evacuation is incomplete due to inaccessible objects - это самая плохая ситуация, говорящая о том, что дисковые объекты degraded-устройства недоступны. Если добавление новых ресурсов не помогает, то остается только удалить этот диск из конфигурации vSAN, выбрав опцию "no data migration".
4. Evacuation complete - эвакуация данных завершена, и диск можно безопасно удалить из конфигурации vSAN (не забудьте заменить его рабочим диском).
Многие из вас знают, что на днях компания VMware выпустила обновление виртуального модуля для управления виртуальной инфраструктурой - VMware vCenter Server Appliance 6.7a. В основном, в этом обновлении были исправлены ошибки, связанные с апгрейдом на новую версию vSphere 6.7 с прошлых 6.5 и 6.0. Также иногда зависал vSphere Web Client при логине, и эта проблема была тоже исправлена.
Но самое интересное, что и в новой версии vCSA 6.7a тоже есть небольшая проблема апгрейда уже с версии 6.7:) Стандартно процедура обновления виртуального модуля vCenter выглядит так:
1. Через интерфейс CLI.
Добавляем образ VMware-vCenter-Server-Appliance-6.7.0.11000-8546234-patch-FP.iso к серверу vCenter Server Appliance как CD/DVD drive.
Идем на vCSA по SSH как root и выполняем команды:
Для стейджинга ISO: software-packages stage –iso
Для просмотра контента на стейджинге: software-packages list –staged
Для установки rpm-пакетов со стейджинга: software-packages install –staged
2. Через интерфейс VAMI.
Добавляем образ VMware-vCenter-Server-Appliance-6.7.0.11000-8546234-patch-FP.iso к серверу vCenter Server Appliance как CD/DVD drive.
Логинимся в интерфейс VAMI по адресу https://fqdn-of-vcenter:5480
Нажимаем Update и в правом верхнем углу выбираем Check Updates -> Check CD Rom.
Нажимаем Update, затем Stage и Install.
Также это обновление можно сделать по URL новой версии, которая дефолтно должна находиться в рамках процедуры описанной выше, только без присоединения ISO-образа к vCSA. Но сейчас в этом апдейте какие-то проблемы с этим, поэтому когда нажмете кнопку Update в VAMI, то затем надо нажать Settings и добавить туда следующий URL:
Еще в далеком 2011 году мы писали о средстве VMware I/O Analyzer, которое позволяет сгенерировать нагрузку на хранилища VMware vSphere, а после чего замерить производительность этих хранилищ. Делается это средствами интегрированного фреймворка, который поддерживает распределенную архитектуру - центральный управляющий виртуальный модуль и воркеры (генераторы нагрузки).
В 2014 году это средство еще раз обновилось для поддержки актуальных на тот момент версий ESXi, ну а на днях появилось обновление VMware I/O Analyzer 1.6.2u1, которое поддерживает VMware vSphere 6.5 и более поздние версии, то есть vSphere 6.7.
Напомним основные возможности VMware I/O Analyzer:
Интегрированный фрейворк для тестирования производительности хранилищ.
Простая настройка и возможность исполнения тестов на одном или нескольких хостах ESX/ESXi.
Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС.
Возможность экспорта данных для последующего анализа.
Средства "повторения" нагрузки на хранилища путем ее воспроизведения из трейса ввода-вывода.
Возможность загрузки трейсов ввода-вывода для автоматического извлечения необходимых метрик.
Графическая визуализация метрик и результатов анализа производительности.
В новой версии I/O Analyzer 1.6.2u1 появились следующие фичи:
Поддержка последних версий vSphere.
Обновление протокола до версии OpenSSL 1.0.2o.
Сценарий для горячего обновления с прошлой версии 1.6.2.
В прошлой версии 1.6.2 были пофикшены уязвимости Shellshock и Heartbleed.
Скачать VMware I/O Analyzer 1.6.2u1 можно по этой ссылке. Инструкция к данному средству тестирования доступна тут.
Компания VMware на днях объявила о скором выпуске новой версии решения VMware Integrated OpenStack 5.0 (VIO), предназначенного для построения инфраструктуры OpenStack на базе платформы виртуализации VMware vSphere за счет развертывания виртуального модуля vSphere OpenStack Virtual Appliance (VOVA). Напомним, что о прошлой версии - VMware Integrated OpenStack 4.1, мы писали в январе этого года вот тут. В первую очередь, новый релиз VIO 5.0 направлен на поддержку дистрибутива OpenStack Queens, который можно использовать совместно с решениями vSAN и NSX.
Давайте посмотрим, что нового появилось в пятой версии решения Integrated OpenStack 5.0:
Расширенная поддержка Kubernetes:
VIO 5.0 идет с дистрибутивом Kubernetes версии 1.9.2. Также включена поддержка релиза NSX-T 2.2. Пользователи Kubernetes могут использовать решение N-VDS через плагин Multus CNI. Также поддерживается Red Hat Enterprise Linux в качестве образа для кластера K8S.
Гетерогенные кластеры за счет использования Node Group - теперь можно использовать различные типы узлов-воркеров в рамках одного кластера. Теперь кластер может иметь несколько node groups, каждая из которых мапится на профиль узла. Это позволяет более эффективно использовать ресурсы для различных типов нагрузок в одном кластере.
Функции vkube heal позволяют зайти на узел кластера по ssh и восстановить его на базе состояния ETCD state или из резервной копии в случае полного сбоя всего кластера.
Расширенные возможности сетевого взаимодействия:
N-VDS - также известен как NSX-T VDS в режиме Enhanced Data-path. Позволяет компоненту N-VDS работать в режиме DPDK, что дает улучшения производительности для контейнеров и ВМ.
NSX-V Search domain - новая настройка NSX-V позволяет администратору настроить global search domain. Клиенты облака будут использовать этот домен поиска, если он не задан отдельно для его подсети.
NSX-V Exclusive DHCP server per Project - вместо общего DHCP edge, основанного на подсетях для нескольких проектов, теперь появилась возможность назначить DHCP-серверы для сетевого сегмента отдельного проекта. Это позволяет обеспечить лучшую изоляцию клиентов и их проектов.
NSX-T availability zone (AZ) - зона доступности используются для обеспечения высокой доступности сетевых узлов, которые поддерживают такие сервисы, как DHCP, L3, NAT и прочие.
Возможности безопасности:
Keystone Federation - функции Federated Identity позволяют безопасно использовать единые креденшелы для доступа к облачным ресурсам, таким как серверы, тома и базы данных, между различными устройствами доступа и облачными средами. Также обеспечивается поддержка функций Keystone to Keystone (K2K) federation.
Поддержка Gnocchi - это название проекта TDBaaS (Time Series Database as a Service), который позволяет ускорить работу архитектуры Ceilometer за счет более эффективной организации хранилищ для биллинга и мониторинга.
Default Drop Policy - позволяет убедиться в том, что трафик к порту, для которого не прописаны security groups и включена настройка port security, всегда будет сбрасываться.
End to End Encryption - администратор теперь имеет возможность включить шифрование API для внутренних вызовов (TLS 1.2) в дополнение к публичным вызовам через OpenStack endpoints. Это позволяет избежать внутренних угроз в инфраструктуре.
Производительность и управляемость:
VIO-in-a-box - также известный как развертывание типа "Tiny". Все компоненты OpenStack теперь можно развернуть на одном физическом сервере. Это можно сделать вручную или через OMS API.
Функции Hardware Acceleration - теперь появилась поддержка vGPU для требовательных к графике нагрузок.
Улучшенная масштабируемость OpenStack - инфраструктура VIO 5 была протестирована на 500 хостах и 15 000 виртуальных машинах в рамках одного региона (в этом релизе поддерживается несколько регионов).
Возможность Elastic TvDC - датацентр уровня клиента (Tenant Virtual Datacenter, TvDC) может быть расширен на несколько кластеров в VIO 5.0. Администратор может создать несколько пулов ресурсов, объединяющих ресурсы нескольких кластеров с одним именем, project-id и уникальным provider-id. Когда клиент облака запускает новый инстанс, планировщик OpenStack выделит для ВМ один из пулов ресурсов, замапленных на этот объект TvDC.
Решение VMware Integrated OpenStack 5.0 будет доступно для загрузки до 3 августа 2018 года.
Некоторые из вас знают, что недавно (с 14 по 16 мая) в Чикаго прошла конференция VeeamON 2018, в рамках которой компания Veeam Software рассказала о будущих новых продуктах и технологиях, а также выпустила пару новых версий различных решений (более подробно об этом тут, тут и тут).
Среди анонсов будущих продуктов - новая версия средства для резервного копирования инфраструктуры Microsoft - Veeam Backup for Microsoft Office 365 2.0. С помощью этого решения можно производить резервное копирование и восстановления данных Office 365 из облака, а также бэкапить локальные данные Microsoft Exchange, OneDrive и Sharepoint.
Напомним, что о Backup for Microsoft Office 365 1.5 мы писали осенью прошлого года вот тут.
Функция Data Protection for OneDrive for Business - теперь появилась возможность защиты данных (включая заметки OneNote) предприятия, которое хранит свои данные в облаке Microsoft. Для этого был сделан специальный мастер Veeam Explorer for Microsoft OneDrive. В этом решении будет сделана полная поддержка версионности, а также PowerShell и REST API. Кстати, при восстановлении файлов будет возможность восстановления и прав доступа, которые были у них изначально.
Функция Data Protection for SharePoint - кроме OneDrive решение от Veeam может бэкапить инфраструктуру Sharepoint - как облачное решение SharePoint Online, так и онпремизные данные - сайты, документы, библиотеки и списки. Это все было добавлено в Veeam Explorer for Microsoft SharePoint. Также возможен бэкап домашней страницы и сохранение прав доступа объектов при восстановлении.
Полностью переработанный интерфейс мастера задач, что упрощает настройку и обслуживание инфраструктуры резервного копирования. Помимо этого, было сделано много улучшений бэкапа Exchange, таких как поддержка выбора пользователей из групп, поддержка ящиков group/team, работа с PowerShell/REST и многое другое.
Кроме всего этого, появилась бесплатная версия Veeam Backup for Microsoft Office 365 Free Edition, которая полностью сохраняет все функции коммерческого продукта, но имеет следующие ограничения:
Максимальное число пользователей Exchange - 10.
Максимальное число пользователей OneDrive for Business - 10 (те же самые аккаунты, что и в предыдущем пункте).
Максимальный объем защищаемых данных Sharepont - 1 ТБ.
Поддержка для этой версии будет предоставляться без гарантий SLA.
Новая версия Veeam Backup for Microsoft Office 365 2.0 будет доступна в конце второго квартала (или в начале третьего). Бета-версия решения уже доступна, попросить ее можно у поддержки Veeam.
Распределенный файервол, или DFW (Distributed Firewall), – популярная функция NSX. С выходом vCloud Director 8.20 инструмент стал доступен клиентам вместе с новым интерфейсом HTML5 и API. Управление файерволом осуществляется на уровне Org vDC.
Использование опции Manage Firewall для управления DFW
Если кликнуть по ссылке Manage Firewall в свойствах виртуального ЦОД, откроется окно управления DFW, которое выглядит так:
Окно управления Distributed Firewall
Как сказано в официальной документации, Distributed Firewall представляет собой брандмауэр, реализованный на уровне ядра гипервизора, который обеспечивает контроль сети и виртуализированных нагрузок. Здесь можно создавать политики на основе объектов VMware vCenter, таких как дата-центры, кластеры, виртуальные машины, используя в том числе комбинации из IP-адреса или наборов IP-адресов, VLAN, VXLAN, групп безопасности, включая объекты Active Directory. Правила брандмауэра работают на уровне отдельно взятой виртуальной машины и не зависят от сетевой топологи, что обеспечивает постоянный контроль доступа, даже когда ВМпереходит в режим работы vMotion. Такая «нативность» с гипервизором дает файерволу большие преимущества, поскольку обеспечивается максимальная пропускная способность и более высокая консолидация рабочих нагрузок на физических серверах. Кроме того, файервол поддерживает масштабируемую архитектуру, благодаря чему при добавлении в ЦОД новых узлов автоматически увеличивается пропускная способность брандмауэра...
Рабочая среда Citrix объединяет функциональные возможности и обеспечивает защиту мобильных, виртуальных и SaaS-приложений и контента на всех рабочих местах.
Анахайм, шт. Калифорния, 10 мая 2018 года – Цифровая трансформация, облачные технологии и новые способы решения рабочих задач заставляют компании пересмотреть свое отношение к традиционным методам развертывания приложений и обеспечения их защиты.
На этой неделе в рамках Citrix Synergy компания Citrix представляет новые технологии, которые поддержат переход на модель компьютерных вычислений, ориентированных на потребности человека. Это позволит компаниям объединить все необходимые для их сотрудников инструменты в одном решении и при этом обеспечить надежную защиту и соответствие нормативным требованиям. Чтобы сохранить высокий уровень вовлеченности сотрудников в общий процесс работы, компании должны обеспечить унифицированные функциональные возможности, которые будут адаптироваться в соответствии с тем, где выполняется работа; предоставят ИТ-специалистам возможность эффективно поддерживать и управлять работой всех сетей, облачных сред и устройств; создадут согласованную защищенную среду, которая будет динамически обнаруживать и применять политики в любом месте, начиная с дата-центром, и заканчивая самым удаленным конечным устройством.
«Мы в компании Citrix стремимся реализовать модель компьютерных вычислений, ориентированных на потребности человека. В современном мире права, обязанности и компетенции мобильных специалистов и сотрудников, которые работают в традиционных офисных средах, равны. Поэтому компании должны предоставлять им одинаковые условия и инструменты для выполнения работы. Наши решения предоставляют необходимый функционал, высокий уровень безопасности и широкие возможности для выбора, которые необходимы сотрудникам и компаниям, чтобы создавать новые продукты, активнее работать с заказчиками и сохранять свою производительность в любое время и в любом месте», – сказал Дэвид Хеншелл (David Henshall), главный исполнительный директор компании Citrix.
Объединяя удобство мобильных, виртуальных, а также SaaS-приложений
Удобство и производительность работы сотрудников стали главным приоритетом для руководителей компаний. Если обеспечить надежный доступ к приложениям, устройствам и контенту по желанию сотрудника, то можно увеличить производительность работы и эффективность бизнеса в целом. Предоставляемая среда должна быть адаптивной и персонализированной. Citrix расширяет возможности доступа к виртуальным, настольным и мобильным приложениям, чтобы предоставить защищенный доступ к SaaS-приложениям и контенту через Citrix Workspace, что создает первую объединённую цифровую рабочую среду для бизнеса.
Citrix является единственной компанией, предлагающей самую полную и интегрированную рабочую среду, которая позволит пользователям получить защищенный доступ к своим веб-, SaaS-, Windows, Linux и мобильным приложениям, рабочим местам и данным из любого места и с любого устройства. Citrix Workspace предоставляет пользователям защищенный доступ с возможностью однократной идентификацией ко всем приложениям и контенту в рамках цифровой, интуитивно понятной рабочей среды, которая создает согласованный и объединённый интерфейс пользователя на всех устройствах. Это даёт возможность пользователю начать работу дома со своего планшета, затем продолжить её на смартфоне во время поездки в офис и завершить в офисе, используя рабочий настольный или мобильный ПК.
Интегрированная с уже проверенными сетевыми решениями и средой для совместного использования файлов, технология Citrix Workspace гарантирует надёжную производительную работу ПО, встроенный поиск и автоматизацию процессов для всех приложений, вне зависимости от места хранения документов. Citrix продолжает улучшать удобство работы и функциональные возможности своих мобильных приложений и добавляет интеграцию со Slack в Secure Mail, чтобы пользователи могли преобразовывать сообщения электронной почты в сообщения Slack и отправлять их непосредственно из Secure Mail.
Широкие возможности для выбора без дополнительных сложностей
Сервисы Citrix Cloud поддерживают переносимость облачных сред, чтобы дать заказчикам необходимые инструменты и данные для уверенной реализации персонализированных облачных стратегий и гибкости для лёгкого перемещения рабочих нагрузок между облачными средами по мере изменения потребностей бизнеса. Теперь заказчики могут запускать свои рабочие нагрузки Citrix в любом облаке – AWS, Azure, Google, Oracle или частных средах. Технологии автоматизированного управления образами и предоставления ресурсов компании Citrix поддерживают широкий набор различных платформ: начиная от тех, что работают без операционных систем или с виртуализированными инфраструктурами, заканчивая облачными средами. Citrix организовала весь своей стек на базе единой платформы, поэтому заказчики могут легко переносить свои рабочие нагрузки из ЦОД в облачные среды по своему выбору и по мере необходимости, реализуя функцию мобильности облачных технологий в корпоративном секторе.
Citrix продолжает сотрудничать с Microsoft для того, чтобы реализовать дополнительные функции на базе Remote Desktop Management Infrastructure (RDMI), следующего поколения RDS-платформы для Azure. Citrix также будет предлагать поддержку Windows Server 2019 с первого дня выхода этой системы, чтобы осуществлять доставку виртуализированных приложений с помощью XenApp.
Кроме того, Citrix предлагает возможность выбора устройств с помощью одного решения для управления конечными системами. Citrix Endpoint Management обеспечивает управление самым широким набором устройств, начиная с носимых устройств, заканчивая техникой из концепции Интернета вещей, включая Alexa for Business, а также устройства Raspberry Pi с поддержкой Workspace Hub от партнёров Citrix NComputing и Viewsonic. Современным компаниям необходимо современное решение для управления всем этим разнообразием устройств – выбор не ограничивается только телефонами и мобильными ПК. Вне зависимости от используемого устройства, Citrix может защищено управлять всеми конечными устройствами в рамках компании.
Надежная защита: современный комплексный подход
Новые угрозы требуют современного подхода к обеспечению безопасности, который в том числе будет способствовать повышению, а не снижению производительности. Компании нуждаются в комплексном подходе, который будет адаптироваться к тому, как выполняют свои задачи сотрудники, а не заставлять их работать в рамках установленных правил. Расширенный подход к безопасности Citrix объединяет линейку продуктов Citrix Networking, занимающую лидирующее положение на рынке, Citrix Unified Endpoint Management и Citrix Analytics для создания защищенного цифрового периметра, который окружает пользователей, приложения и сети для более детального контроля. Защищенный цифровой периметр Citrix использует централизованные политики контроля безопасности, которые применяются динамично в любой точке доступа для максимального сокращения и скрытия поверхности атак злоумышленников в локальных, гибридных и мультиоблачных сетях.
Ассортимент сетевых продуктов для цифровых рабочих мест компании Citrix дополнен решением Citrix Analytics. Занимается ли компания обеспечением защиты облачных приложений, файлов и данных, мобильных или настольных приложений, решение Citrix Analytics позволит получить информацию о поведении пользователя, состоянии системы безопасности, скорости работы и выполняемых операциях. Используя технологии машинного обучения и искусственного интеллекта для обнаружения аномального поведения и возможных угроз Citrix Analytics может предоставить применимые на практике интеллектуальные действия на основе информации, собранной с облачных сервисов и локально установленных решений, чтобы заказчики могли в проактивном режиме находить и управлять внешними и внутренними угрозами.
Citrix объединяет удобство работы SaaS-, веб-, мобильных и виртуальных приложений с помощью Citrix Workspace и расширяет свои возможности для защищенного и централизованного управления этими приложениями с помощью Citrix Access Control. В отличие от традиционных SSO-решений, которые не позволяют контролировать данные в SaaS- и веб-приложениях, решение Citrix Access Control предоставляет функциональные возможности SSO для всех SaaS-, веб- и виртуализированных приложений Citrix. Оно предоставляет детальный контроль за политиками, включая технологию водяных знаков, введение ограничений по операциям Copy-Paste и блокировку функции печати. Кроме того, Citrix Access Control и Citrix Analytics предоставляют данные расширенной аналитики поведения пользователей, что позволяет в интеллектуальном режиме перенаправлять подозрительную активность в сети Интернет в облачный виртуальный браузер с полной изоляцией от корпоративной сети и без необходимости настройки конфигурации на конечном устройстве. Это дает возможность компаниям сбалансировать безопасность и использование ресурсов сети Интернет.
«Сохранение производительности в условиях, когда постоянно изменяются формат и стиль работы и стремительно растет динамика и сложность рабочих процессов, требует нового подхода к доставке рабочей среды, которая в первую очередь ориентирована на сотрудника и на то, как он использует технологии для выполнения своих рабочих задач. Citrix Workspace – это первая объединённая цифровая рабочая среда, которая упрощает доступ к приложениям и данным, предлагая одинаковые функциональные возможности на всех устройствах», – сказал Пи Джей Хаф (PJ Hough), старший вице-президент по продуктам и технологиям компании Citrix.
Недавно я начал своё знакомство с Nutanix и первым делом скачал и опробовал NutanixCmdlets PowerShell Snap-in. Сразу выяснилось, что набор командлетов далеко не полный, и многого не хватает. Тут же созрело решение создать вспомогательный Power-NTNX модуль как в своё время я сделал Vi-Module для VMware. Модуль будет обновляться и пополняться по мере возможности и надобности, и с каждой новой функцией будет выходить статья. Уже сегодня есть задумки на 3-4 функции. И первой функцией будет Wait-NTNXTask.
Мы много писали о релизе новой версии платформы виртуализации VMware vSphere 6.7 и ее возможностях, а сегодня хотим рассказать про нововведения функции Instant Clone, о которых написал Дункан Эппинг. Напомним, что функция мгновенного клонирования виртуальной машины (ранее известная как VMFork) позволяет очень быстро сделать работающую копию запущенной ВМ на платформе VMware vSphere.
Делается это за счет того, что "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory) на чтение, что и родительская ВМ. При этом дочерняя ВМ в общую память писать не может, а для записи собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ:
Такая схема использования родительской ВМ в VMware vSphere 6.5 требовала, чтобы родительская машина и ее мгновенные клоны находились на одном сервере ESXi. А значит для этих ВМ не поддерживались такие технологии, как vMotion/HA/Storage vMotion и DRS. Между тем, это очень важно для служб тестирования, отделов DevOps и т.п.
Теперь же в VMware vSphere 6.7 появились следующие улучшения Instant Clone:
Появился простейший публичный API, который позволяет автоматизировать процесс создания и перемещения мгновенных клонов. Он умеет пока не все, но будет развиваться. GUI для этого пока также нет.
Интеграция с технологиями vSphere для обеспечения доступности виртуальных машин (HA, DRS, vMotion, Storage / XvMotion и т.п.).
Поддержка двух рабочих процессов создания мгновенных клонов: первый - это последовательное создание клонов в процессе работы родительской виртуальной машины, второй - отпочковывание клонов от "замороженной" родительской ВМ.
Использование технологии P-Share для дедупликации страниц памяти средствами технологии Transparent Page Sharing (даже когда она отключена на хосте ESXi).
Теперь отношение родитель-клон не такое тесно связанное, как раньше.
Давайте посмотрим на первый рабочий процесс - создание мгновенных клонов работающей ВМ. Это, например, может пригодиться, когда вы массово тестируете обновление компонентов какого-либо приложения. Обновили первый компонент - сделали несколько клонов для тесткейсов, провели тесты, потом обновили следующий - и снова сделали несколько клонов для тестирования.
Схематично это выглядит вот так:
У родительской ВМ создается дельта-диск, который используется первым мгновенным клоном, потом базовая ВМ несколько меняется за время до создания следующего - и на момент создания нового мгновенного клона будет использоваться уже следующий дельта-диск и так далее. Пока для этого нет визуального интерфейса, но все это можно потестировать через MOB-браузер.
Такая схема имеет недостаток в том, что у родительской ВМ плодятся дельта-диски, что приводит к тому, что быстродействие родительской ВМ замедляется, а сама структура за счет увеличения числа дисков существенно усложняется, что потенциально может привести к различного рода сбоям.
Также в данном случае есть проблема сетевой идентификации - все виртуальные машины, которые рождаются как мгновенные клоны имеют те же настройки IP и MAC-адреса, что и родитель. Чтобы изменить их потребуется выполнить следующие действия:
После создания Instant Clone внутри нужно отключить сетевой интерфейс через свойство VirtualEthernetCard->connectable->migrateConnect, устанавливаемое в значение disconnect. Далее нужно задать настройки сетевой идентификации ВМ.
Если не хочется менять параметры сетевой идентификации, новые ВМ можно просто запускать в отдельной портгруппе, без выхода во внешнюю сеть во избежание конфликтов IP и MAC-адресов.
Внутри мгновенного клона нужно обновить настройки сетевого интерфейса, чтобы гостевая ОС получила новый MAC-адрес. Это можно автоматизировать через Guest Operations API.
Снова присоединить виртуальную сетевую карту к ВМ, чтобы новые настройки были применены и машина свободно работала в сети. Для этого нужно установить значение свойства VirtualEthernetCard->connectable->connected в true.
Вторая схема - это "заморозка" родительской ВМ таким образом, что ее CPU перестает исполнять инструкции (для этого используется функция instantclone.freeze в утилите vmware-rpctool). После этого механизм Instant Clone способен создавать связанные клоны этой подмороженной ВМ.
Это позволяет не плодить дельта-диски родительской ВМ (так как ее состояние не изменяется) и достичь унифицированной конфигурации мгновенных клонов:
Такая схема может подойти для масштабирования каких-либо типовых унифицированных нагрузок в виртуальных машинах - например, VDI, хосты с контейнерами, Hadoop-воркеры и так далее.
Поморозка ВМ происходит средствами утилиты vmware-rpctool, которая развертывается в виртуальной машине вместе с VMware Tools.
Также теперь мгновенные клоны существенно меньше привязаны к родительской ВМ, что позволяет использовать их более широко, а сами они называются "parentless".
Ну и напоследок обзорное видео от Дункана, посвященное использованию Instant Clones в платформе VMware vSphere 6.7:
Кроме этого, советуем также почитать вот эту статью Вильяма Лама, посвященную мгновенным клонам.
Как все уже знают, недавно компания VMware выпустила обновленную версию платформы виртуализации VMware vSphere 6.7. Напомним наши статьи о нововведениях этого решения:
Ну а сегодня мы расскажем еще об одной возможности vSphere в плане безопасности - поддержке технологии Virtualization Based Security (VBS) операционных систем Microsoft. Механизм VBS позволяет превратить сервер или рабочую станцию на базе ОС Windows Server 2016 или Windows 10 в защищенные системы, исполняющиеся в рамках гипервизора Windows, при этом некоторые компоненты выносятся за пределы гостевой системы. Например, за рамки ОС выносится система управления хэшированными парами логин/пароль (креденшены), называющаяся Credential Guard.
Как мы видим на картинке, гипервизор обеспечивает виртуализацию гостевой системы на сервере или ноутбуке, а также канал обмена между внешними компонентами (Credential Guard, Device Guard) и ОС. Такая архитектура обеспечивает большие трудности при доступе злоумышленников к областям памяти, где хранятся хэши паролей различных пользователей - ведь эта область вынесена за пределы операционной системы.
Также аппаратное обеспечение компьютера должно иметь в своем составе модуль TPM 2.0 (Trusted Platform Module), который обеспечивает механику безопасной загрузки (Secure Boot). Ведь если не использовать механизм безопасной загрузки, то атаку можно провести на сам гипервизор, подменив его компоненты, а дальше уже иметь доступ к основной виртуальной машине и остальным компонентам гипервизора, в том числе хранилищу паролей. Таким образом, для полной защиты нужно использовать связку VBS+TPM 2.0 (вторая версия TPM поставляется уже со всем современным оборудованием).
Чтобы такая схема работала, нужно обеспечить выполнение следующих требований:
UEFI firmware (не BIOS).
Опция безопасной загрузки Secure Boot с поддержкой TPM.
Поддержка технологии Hardware virtualization (опция процессоров Intel VT/AMD-V) и функций IOMMU.
И самое главное - ОС Windows должна быть установлена со всеми этими включенными опциями, иначе потом настраивать VBS будет проблематично.
В случае с гипервизором ESXi для незащищенной виртуальной машины Windows все выглядит вот таким образом:
Чтобы защитить машину с помощью VBS, потребуется использовать вложенную (nested) виртуализацию - ведь гипервизор Windows Hypervisor надо запустить на платформе VMware ESXi. Для этого в настройках виртуальной машины надо выставить опцию Enable для пункта Virtualization Based Security:
Это позволит открыть все необходимые опции процессора для гостевой ОС виртуальной машины, в которой также будет работать гипервизор.
Выглядеть это будет следующим образом:
Чтобы эта схема работала, нужно выполнить 2 условия:
Виртуальная машина должна иметь виртуальное железо Virtual Hardware версии 14, которое появилось в vSphere 6.7.
Гостевую ОС виртуальной машины надо развертывать на базе UEFI и с уже включенной опцией Secure Boot (обратите внимание на эту опцию на панели Boot Options в разделе VM Options (см. скриншот настроек выше).
Ну и последняя деталь - это модуль TPM. Для физических систем этот модуль делается с расчетом на одну систему, имеет небольшой объем памяти защищенного хранилища (измеряется в килобайтах) и работает весьма медленно, так как это serial device.
Поэтому VMware сделала виртуальное устройство - vTPM 2.0, которое в качестве хранилища использует обычный файл .nvram. Физический TPM не рассчитан на то, чтобы поддерживать сотни виртуальных машин на одном сервере (просто не хватит объема хранилища и быстродействия), а виртуальный vTPM отлично справляется с этой задачей. К тому же, виртуальную машину с виртуальным vTPM можно переносить между серверами с помощью vMotion и делать ее резервные копии.
Но, само собой, файл nvram надо хорошо зашифровать, поэтому для виртуальной машины нужно включить VM Encryption. Это обеспечит работоспособность машины в защищенной среде совместно с опцией VBS. При этом диски ВМ шифрованными не будут, что позволит получить доступ к данным на уровне VMDK дисков в случае утери ключей.
Самое интересное, что vTPM 2.0 не требуется как-то отдельно устанавливать и настраивать - он автоматически обнаруживается средствами Windows со стандартными драйверами:
Утилита Device Guard and Credential Guard hardware readiness tool от компании Microsoft определяет этот vTPM, как совместимый, поэтому можете использовать его для виртуальных машин, к которым предъявляются повышенные требования к безопасности.
Как вы все уже знаете, недавно компания VMware выпустила обновленную версию платформы виртуализации VMware vSphere 6.7. Помимо описания новых возможностей решения мы также останавливались на новых функциях VMware vCenrer 6.7, а сегодня расскажем о некоторых нововведениях тонкого клиента VMware vSphere Client 6.7, построенного на базе технологии HTML5.
Напомним, что vSphere Client не удалось добить до полной функциональности, поэтому VMware выпустила и финальный релиз vSphere Web Client 6.7 на базе технологии Flash. Но обещают, что функционал клиентов уже почти одинаковый. Одним из шагов на пути к этому стала поддержка основных рабочих процессов vSphere Update Manager (VUM) в HTML5-клиенте.
Надо начать с того, что интерфейс VUM был полностью переработан, а не просто скопирован с Web Client. Рабочие процессы стали проще и понятнее.
Кстати, обратите внимание на гифке выше, как удобно теперь стало искать обновления для хостов ESXi с помощью встроенного в таблицу со списком апдейтов поля поиска.
Многошаговый мастер по обновлению хостов ESXi 6.0-6.7 был заменен простым рабочим процессом, в рамках которого процедура remediation требует лишь нескольких кликов:
Также процедура предварительной проверки кластера (pre-check) была вынесена в отдельный рабочий процесс, чтобы не инициировать воркфлоу обновления напрасно.
Между тем, не все рабочие процессы VUM были реализованы - в новой версии этого средства нет обновления VMware Tools и средств проверки совместимости "железа" (hardware compatibility). Но их обещают включить в ближайшем релизе.
Также существенно был ускорен процесс обновления с vSphere 6.5 на vSphere 6.7. Если раньше перед проведением обновления нужно было перезагрузить ESXi, а потом еще и после во второй раз, то теперь само обновление за счет оптимизаций идет быстрее, а перезагрузка требуется всего одна.
Помимо этого, теперь информация об обновлениях более полная и включает в себя критичность апдейта, требуется ли перезагрузка, что именно находится внутри и т.п.
На днях компания VMware объявила о выпуске обновленной версии платформы виртуализации VMware vSphere 6.7 (она уже доступна для скачивания). Сегодня мы расскажем о новой версии управляющего сервера VMware vCenter 6.7 и его новых возможностях.
Начать надо с того, что виртуальный модуль VMware vCenter Server Appliance (vCSA) 6.7 теперь рекомендован для развертывания по умолчанию, а значит VMware уже окончательно рекомендует перейти на этот вариант средства управления виртуальной инфраструктурой.
1. Средства управления жизненным циклом.
Об этом мы уже упоминали в статье про vSphere 6.7. Теперь vCenter Server Appliance 6.7 позволяет развернуть vCenter Server с внедренным компонентом Embedded PSC и поддержкой Enhanced Linked Mode. Это дает следующие преимущества:
Теперь для высокой доступности vCSA не нужен балансировщик, и технология vCenter Server High Availability поддерживается нативно.
Теперь проще развертывать инфраструктуру Single Sign-On Domain.
Поддержка максимумов масштабирования vSphere.
Можно делать до 15 развертываний vCSA в рамках одного домена vSphere SSO.
Уменьшение числа узлов, которые надо обслуживать и поддерживать.
Также в составе vSphere 6.7 есть последняя версия vCenter Server 6.7 for Windows, которая уже не будет доступна в следующих версиях платформы. Теперь при миграции старого vCenter на vCSA есть две опции по импорту исторических данных БД:
Развертывание и мгновенный импорт данных
Развертывание и импорт данных в фоновом режиме
При этом показывается примерное время простоя сервисов vCenter во время этих процессов:
Также если вы выбрали импорт данных в бэкграунде, то потом можете поставить этот процесс на паузу. Помимо этого, был улучшен интерфейс процесса миграции, а также появилась возможность выбрать кастомные порты, чтобы не перенастраивать фаервол.
Что касается апгрейда с прошлых версий, то vCenter поддерживает только обновление с vSphere 6.0 и 6.5, а vSphere 5.5 остался в пролете, хотя все еще много пользователей этой версии. Таким клиентам надо будет делать чистую установку или мигрировать сначала на 6.0/6.5 (лучше, все же, ставить заново).
Кстати, помните, что конец поддержки vSphere 5.5 наступает 19 сентября 2018 года.
2. Мониторинг и управление.
В первую очередь надо сказать, что интерфейс инструментария vSphere Appliance Management Interface (VAMI) теперь построен на базе фреймворка Clarity, что делает работу с vCSA простой и приятной:
Теперь при управлении vCSA можно пользоваться отдельным разделом Monitoring для проверки состояния виртуального модуля, а также появилась вкладка Disks, где видны разделы vCSA и их заполненность.
Также появилась вкладка Services, где можно смотреть за состоянием служб vCSA. Кроме этого, были улучшены службы Syslog (теперь можно использовать до трех таргетов), а также Update (теперь можно выбрать патч или апдейт, который будет накатываться). Из VAMI теперь можно отправить патч на стейджинг и потом поставить его, ранее это было доступно только через CLI.
Помимо этого, теперь информация об обновлениях более полная и включает в себя критичность апдейта, требуется ли перезагрузка, что именно внутри и т.п.
Ну и одна из главных ожидаемых возможностей - бэкап сервера vCSA на уровне файлов. Теперь можно задать расписание резервного копирования и сколько резервных копий сохранять:
Помимо бэкапа есть и восстановление, конечно. При этом браузер архивных копий показывает их все, без необходимости искать пути до этих бэкапов.
3. Улучшения vSphere Client.
Теперь в HTML5-клиенте vSphere Client появились обновленные рабочие процессы для следующей функциональности:
vSphere Update Manager
Content Library
vSAN
Storage Policies
Host Profiles
vDS Topology Diagram
Licensing
Но, поскольку vSphere Client не удалось добить до полной функциональности, VMware выпустила и финальный релиз vSphere Web Client 6.7 на базе технологии Flash. Но обещают, что функционал уже почти одинаковый.
Из нового в vSphere Client - появились фичи Platform Services Controller (PSC) UI (/psc), которыми можно управлять через раздел Administration. Кроме этого, появилась отдельная вкладка Certificate management в разделе Configuration.
4. Утилиты CLI.
Вернулась утилита cmsso-util, которая может делать отчеты по виртуальным модулям vCSA, находящимися в рамках одного SSO-домена. Также можно сравнить 2 домена SSO и выгрузить в JSON-файл различия между этими доменами. Кроме этого, можно мигрировать лицензии, тэги, категории и права доступа из одного домена SSO в другой.
Второе улучшение CLI - это установщик vCSA, который позволяет управлять жизненным циклом этого виртуального модуля. vCenter Server Appliance ISO идет вместе с примерами JSON-шаблонов развертывания. Эти шаблоны можно использовать для унификации развертывания серверов vCenter, накатывая эти JSON в пакетном режиме друг за другом. Это позволяет убедиться в унификации конфигурации всех узлов vCenter в рамках больших инсталляций на нескольких площадках.
Скачать платформу VMware vSphere 6.7, содержащую управляющие компоненты VMware vCenter 6.7 и vCSA 6.7 можно по этой ссылке.
VMware vForum Online provides expert insight that can help drive innovation for your organization. It’s a must-attend event for IT professionals who are driving their digital transformation and building a hyper-converged IT infrastructure. Таги:
На днях компания VMware выпустила Configuration Maximums Tool - средство, которое позволяет посмотреть максимумы конфигурации платформ виртуализации, виртуальных машин и других решений VMware в различных категориях. На данный момент поддерживаются версии VMware vSphere 6.0, 6.5 и 6.5 Update 1 (кстати о сравнении максимумов 6.5 и 6.0 мы писали вот тут).
По умолчанию мы видим следующие Configuration Maximums, которые можно сворачивать-разворачивать в пределах категории:
Virtual Machine Maximums
ESXi Host Maximums (Compute)
ESXi Host Maximums (Memory)
ESXi Host Maximums (Storage)
ESXi Host Maximums (Networking)
ESXi Host Maximums (Cluster and Resource Pools)
ESXi Host Maximums (VMDirectPath)
vCenter Server Maximums
vCenter Server Maximums (Storage DRS)
Platform Services Controller
vCenter Server Extensions (Update Manager)
vCenter Server Extensions (vRealize Orchestrator)
VMware vSphere Flash Read Cache
VMware vSAN
Virtual Volumes
Также многим будет интересна фича сравнения максимумов различных версий VMware vSphere:
Сравнить можно 2 или 3 версии платформы, а результат выгрузить в XLS-файл, чтобы использовать его в MS Excel.
Многие администраторы платформы VMware vSphere заметили, что в версии VMware vSphere 6.5 несколько поменялся механизм запуска виртуальных машин в случае сбоя в кластере HA. Об этом интересно недавно написал Дункан Эппинг.
Напомним, что приоритет HA Restart Priority нужен для того, чтобы виртуальные машины могли запуститься в определенном порядке, и их сервисы корректно подхватили уже работающие приложения, запущенные предыдущей очередью ВМ. Всего один хост VMware ESXi может одновременно начать запуск до 32 виртуальных машин, поэтому в большом кластере с большим числом ВМ это действие нужно приоритизировать.
С точки зрения наступления момента запуска следующей очереди набора ВМ есть 4 таких события:
Resources are allocated - это дефолтная настройка в кластере HA. Ресурсы аллоцируются в тот момент, когда master-хост выбрал хосты для восстановления и запуска ВМ. Это занимает совсем небольшое время (миллисекунды).
VMs are powered on - это означает, что машина запустилась, и ESXi считает ее запущенной (но не гостевую ОС). Это занимает иногда 10-20 секунд, а иногда и несколько минут.
Guest heartbeat is detected - это когда от гостевой ОС VMware получает отклик, например, через VMware Tools.
App heartbeat is detected - это когда получен отклик от определенного приложения. В этом случае у вас должен быть настроен VM/Application Monitoring, который позволит оповестить о том, что приложение запустилось, и можно его использовать.
Если вам нужно убедиться, что работает сервис (то есть гостевая ОС и приложения), так как ВМ следующей очереди должны его использовать - то нужно опираться на последние два события.
Теперь приоритет восстановления ВМ (Restart Priority) содержит 5 уровней вместо трех, которые были в vSphere 6.0:
Lowest
Low
Medium
High
Highest
Такие странные названия сделаны в целях совместимости с прошлой классификацией - Low, Medium и High.
Чтобы начать настройку Restart Priority, в vSphere Web Client нужно выбрать кластер HA и перейти на вкладку Configure, после чего выбираем раздел VM Overrides и нажимаем кнопку "Add":
Далее выбираем виртуальные машины, для которых мы хотим задать приоритет запуска:
И здесь главное - это выбор нужного приоритета из пяти уровней и выставление условия "Start next priority VMs when", то есть триггера запуска следующей очереди приоритета:
Все эти настройки применяются и для кластера, в котором не работает vCenter (в случае большого сбоя). Ну и посмотреть текущие настройки приоритетов запуска ВМ в кластере HA можно следующей командой:
/opt/vmware/fdm/fdm/prettyPrint.sh clusterconfig
Вывод будет очень большим, так что ищите в нем текст "restartPriority".
Иногда администраторы пытаются изменить имя хоста для сервера VMware vCenter, vCenter Server Appliance (vCSA) или компонента Platform Services Controller (если он развертывается на отдельном хосте). В этом случае коллеги ищут, как это сделать и натыкаются на вот эту KB 2130599.
Действительно, сделать это никак нельзя (по крайней мере, для VC версий 6.0 и 6.5). У vCenter есть идентификатор PNID (primary network identifier), который также называется System Name во время инсталляции. Он присваивается в момент развертывания vCenter/PSC, и если вы указали FQDN-имя, то PNID им и станет, а если IP-адрес, то он тогда станет PNID.
Если вы указали FQDN-имя, то вы сможете поменять IP-адрес vCenter, и это ни на что не повлияет. Но если же вы при развертывании вбили IP-адрес как System Name, то уже не только имя, но и IP сервера vCenter/vCSA поменять вы не сможете.
Чтобы узнать, какой у вас на сервере PNID, надо выполнить такую команду:
Если же вы, все-таки, поменяете имя vCenter или vCSA, то их службы попросту не смогут запуститься, а в логе vmware-sts-idmd.log вы увидите вот такой текст:
[2015-07-16T08:17:31.353-06:00 vsphere.local 47c25a86-20c3-49c6-9ec0-c5579b36c83d ERROR] [IdentityManager] Failed to authenticate principal [Administrator@domain] for tenant [vsphere.local]
com.vmware.identity.idm.IDMLoginException: Access denied
Ну а в логе vpxd.log - вот такой:
2015-09-01T10:41:51.532-06:00 warning vpxd[03740] [Originator@6876 sub=Default] Failed to connect socket; <io_obj p:0x000000000c4d83d8, h:3392, <TCP '0.0.0.0:0'>, <TCP '</font>IP_Address'>>, e: system:10060(A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond)
2015-09-01T10:41:51.532-06:00 error vpxd[03740] [Originator@6876 sub=HttpConnectionPool-000011] [ConnectComplete] Connect failed to <cs p:0000000008d2dda0, TCP:</font>vcenter.domain.local:443>; cnx: (null), error: class Vmacore::SystemException(A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond)
Кстати, если у вас остался снапшот vCenter до смены имени хоста - можете просто к нему откатиться. Ну или можете сделать бэкап базы VC, развернуть новый сервер с новым System Name и накатить на него этот бэкап.
Это гостевой пост нашего партнера - компании ИТ-ГРАД. «Мир – это книга, и те, кто не путешествует, читают лишь одну ее страницу», – с этим утверждением сложно не согласиться. Ведь путешествия стирают границы, открывают новые горизонты, дарят массу положительных эмоций.
Сегодня практически любая поездка не обходится без высоких технологий: люди привыкли работать с сервисами бронирования отеля или автомобиля, покупки билета или пакетного тура. При этом большинство таких решений размещаются в облаке. О том, как облачные технологии позволяют добиться стабильной работы сервисов, расскажем на примере кейсов отдельных компаний.
Сегодня, когда путешествия доступны практически каждому, сервисы бронирования отелей за рубежом стали еще более востребованными. К счастью, прошли те времена, когда «забукать» отель было чем-то невероятно сложным и приходилось обращаться в турагентства. В эпоху развития онлайн-сервисов увеличилось количество инструментов-агрегаторов, которые позволяют выбрать вариант проживания на любой вкус и кошелек, в любой точке мира, с возможностью оформить резерв, почитать или оставить отзыв, получить круглосуточную техническую поддержку. Вот только не каждый сервис обеспечивает полную прозрачность в отношении цены и предоставляет русскоязычного помощника, способного разобраться в возникшей проблеме. Восемь лет назад ныне популярный бренд hotels.ru исправил эти недочеты. Так появился новый российский сервис, который позволил выводить все доступные цены и способы бронирования с учетом сайтов конкурентов. Но поскольку такой подход подразумевает обработку и анализ огромных массивов данных, которые берутся из различных источников, потребовались серьезные вычислительные мощности. В результате, пройдя путь от покупки и администрирования собственного оборудования, когда ресурсов стало не хватать, а обновление парка серверов и колоссальные вложения в новое железо вызывали вопрос «как быть дальше», решили переехать в облако...Читать статью далее->>
Мы часто пишем о продукте StarWind Virtual SAN, который позволяет организовать кластеры отказоустойчивых хранилищ на базе серверов для виртуальных машин VMware vSphere и Microsoft Hyper-V. В связи с большим интересом к тому, как именно работает это решение с технической точки зрения, постараемся писать об этом побольше. Сегодня мы расскажем об опциональной файловой системе LSFS (Log-Structured File System), которая повышает производительность операций записи и срок службы накопителей.
У некоторых пользователей VMware vSphere при обновлении серверов VMware ESXi возникает проблема - при выполнении команды "esxcli software vib update" в ответ возникает ошибка "No space left on device", хотя с дисками все в порядке, и на них много свободного места, в чем можно убедиться с помощью команды df -h.
Например, появляется вот такой вывод при попытке обновления:
[InstallationError]
[Errno 28] No space left on device
vibs = VMware_bootbank_esx-base_6.5.0-1.41.7967591
Please refer to the log file for more details.
В то же время вывод df -h говорит, что места на всех разделах достаточно:
Очень редко причина такого поведения оказывается проста - на хосте не хватает файловых объектов inodes, как описано в KB 1007638. Это объекты файловой системы, которых может быть до 640 тысяч на одном томе VMFS. Их используемое количество зависит от числа файлов в файловой системе в данный момент.
Проверить наличие свободных inodes можно командой stat -f /:
На картинке мы видим, что запас их еще весьма большой - они почти не израсходованы. Как правило, указанного лимита достичь очень и очень сложно, поэтому чаще всего упомянутое выше сообщение об ошибке связано совсем с другим. Но если вы все же достигли этого лимита, решение тут несложное - удалить какое-то число файлов с ESXi.
Например, можно найти лог-файлы и прочие файлы на хосте ESXi размером более 50 МБ, которые находятся НЕ на томах VMFS (чтобы не задеть логи ВМ), можно следующей командой:
find / -path "/vmfs" -prune -o -type f -size +50000k -exec ls -l '{}' \;
По итогу будет сгенерирован список преимущественно локальных файлов, который будет содержать ISO-образы, большие лог-файлы и т.п., которые уже скорее всего не нужны, и их можно удалить (а лучше переместить на какое-нибудь хранилище в целях архивирования). Также рекомендуем почитать KB 1008643, которая как раз посвящена удалению файлов в целях высвобождения объектов inodes.
Между тем, в случае появления приведенной в начале статьи ошибки о недостатке свободного места очень вероятно, что хост ESXi не может аллоцировать достаточно оперативной памяти (RAM) для проведения обновления. В этом случае вам просто надо включить ESXi system swap, который будет размещен на одном из датасторов, куда будут сбрасываться страницы оперативной памяти при недостатке памяти во время обновления.
Сделать это можно, зайдя в раздел Manage > Settings > System Swap, после чего нажав Edit...:
Выберите датастор и нажмите Ok. Также это можно сделать с помощью функционала Host Profiles:
После выбора датастора для системного свопа обновите хост ESXi и перезагрузите его.
Осенью 2016 года мы писали об утилите для подготовки виртуальных ПК к развертыванию VMware OS Optimization Tool, с помощью которой можно производить тюнинг реестра в целях оптимизации производительности, а также отключение ненужных сервисов и запланированных задач. Это все позволяет создать систему, которую можно будет эффективно использовать в качестве гостевой ОС виртуального ПК предприятия.
С тех пор утилита часто обновлялась и развивалась, исправлялись многочисленные ошибки, а на днях вышла версия VMware OS Optimization Tool b1097.
Давайте посмотрим, что нового появилось в VMware OS Optimization Tool за прошедшие полтора года:
Появилась цифровая подпись дистрибутива.
Обновились шаблоны всех операционных систем Windows 7/8/8.1/10.
Появились шаблоны для Windows server 2016 (RDSH, Server, Desktop).
Добавился новый шаблон App Volumes Packaging Machine, который может быть использован при создании AppStacks на машинах, с помощью которых будут созданы приложения App Volumes.
Фича Template change log - можно добавлять записи об изменениях новой версии шаблона в библиотеке публичных шаблонов.
Документация для утилиты командной строки.
Conditional Check - теперь можно накатывать оптимизацию при наличии определенных условий (например, если установлен заданный ключ реестра в гостевой ОС пользователя).
Проще редактировать шаблон - нет необходимости постоянно нажимать кнопку Update, так как изменения в полях сохраняются автоматически.
Экспорт шаблонов в XML.
TCP Offload включена по умолчанию, так как это сейчас есть на большинстве сетевых карт.
Появилось поле "website", с помощью которого можно отправить пользователей ОС на нужную страничку после развертывания системы.
Кнопка "View in Public Templates", поле для описания шаблона и возможность обновления комментариев.
Много исправлений ошибок, в том числе в последней версии.
Если у вас есть интерес к созданию систем, оптимизированных и готовых к эксплуатации в качестве настольных ПК предприятия, то обязательно скачайте и попробуйте VMware OS Optimization Tool.
В самом конце прошлого года компания VMware выпустила обновление пакета улучшений гостевых систем VMware Tools 10.2.0. А на днях эта ветка пакета обновилась до версии VMware Tools 10.2.5. Напомним, что ветка тулзов 10.2 - это идейный продолжатель первого ответвления 10.1, которое содержит развивающиеся версии для современных гостевых ОС.
Обновленные VMware Tools совместимы с VMware vSphere 5.5 и более поздними версиями платформы, а также с продуктами для настольной виртуализации VMware Workstation и Fusion.
Давайте посмотрим, что нового появилось в VMware Tools 10.2.5:
VMware Tools 10.2.5 поддерживает следующие операционные системы:
Образ windows.iso поддерживает Windows Vista и более поздние ОС.
Образ linux.iso поддерживает Red Hat Enterprise Linux (RHEL) 5 и более поздние, SUSE Linux Enterprise Server (SLES) 11 и позднее, Ubuntu 10.04 и позднее. Также он поддерживает другие дистрибутивы с glibc версии 2.5 и более поздние.
Образ darwin.iso поддерживает Mac OS X версии 10.11 и позднее.
Образ solaris.iso поддерживает какие может версии Solaris.
Изменения драйвера NSX: VMware Tools 10.2.5 поддерживают драйвер vnetWFP от Windows 7 и более поздних ОС.
Возможности Quiesced snapshots - теперь можно исключать некоторые файловые системы из "подмороженных" снапшотов (quiesced snapshots) в гостевых ОС Linux. Эта конфигурация может быть установлена в файле настроек VMware Tools (подробнее написано в документации).
Настройка отключения display resolution mode: в KB 53572 написано о том, как отключить эту настройку. Чтобы не позволить изменять разрешение экрана через VMware Tools, в VMX-файл виртуальной машины нужно добавить строчку: guestInfo.svga.wddm.modeset="FALSE"
Изменения в сетевом драйвере виртуальных сетевых адаптеров виртуальных машин VMXNET3:
Функции Receive Side Scaling (RSS) включены по умолчанию.
Receive Throttle: дефолтное значение этой настройки установлено в 30.
Важно отметить, что эти две настройки не обновят существующие сетевые адаптеры. Новые настройки будут применены только к свеженакатанным VMware Tools или при добавлении новых адаптеров к ВМ. Для обновления существующих адаптеров используйте скрипт. Более подробно об этом рассказано в KB 2008925.
Загрузить VMware Tools 10.2.5 можно по этой ссылке. Release notes доступны тут, а полный набор документации - тут.
RSS
